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^IJsystem to make the telephone call without termination of a current client system to 
network communicatiorti session. ^ 



39. (Newly Aoded) The method of claim 35, wherein said identifier comprises 
a Uniform Resource LocWor (URL) of said targeted network server. 

40. (Newly Adddd) The method of claim 1 , wherein said request comprises an 
identifier which identifies the targeted network server. 

41 . (Newly Added)\rhe method of claim 40, wherein said determining is 
based on said identifier. 

42. (Newly Added) Th^ method of claim 41 , wherein said identifier comprises 
a Uniform Resource Locator (URIjO of said targeted network server. 

43. (Newly Added) The mkhod of claim 41 , said determining comprises a 
step of comparing said identifier in the request with a list of identifiers kept in said 
bridge server corresponding to a plurality of network servers. 



REMARKS 

This is responsive to the Office Action dated February 27, 2003 in the above- 
identified application, in which the Examiner rejects all the pending claims. In particular, 
claim 29 is rejected as being anticipated by Haserodt (US Patent No. 6,031,836) under 
35USC §1 02(e), while other claims are rejected as being obvious over combinations of 
Herz (US Patent No. 5,754,938), Van Hoff (US Patent No. 5,822,539), Haserodt^(US 
Patent No. 6,031 ,836) and Rondeau (US Patent No. 5,850,433) under 35 USC §1 03(a). 
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The applicants have made further amendment to the claims so as to more clearly and 
better define the invention or to perfect claim language, and respectfully traverse the 
rejections of the Examiner based on the amended claims as well as the following detailed 
explanation. 

I. Brief explanation of the present invention 

It is believed a brief explanation of the present invention as claimed will be helpful in 
understanding the patentably distinguishing features in the claims over the cited prior art. 

The present invention teaches a novel technique in determining additional content 
other than the requested content which is requested by a client system and is to be 
provided by a targeted network server. In particular, the additional content is determined in 
a bridge server based on the request . In other words, the determination of the additional 
content is NOT made based upon the requested content , as is conventional in the prior art. 
In a preferred embodiment, the determination is made based on an identifier identifying the 
targeted network server, such as a URL which is typically included in the request. To more 
clearly define the present invention, the applicants have further amended independent 
claims 1 and 19 such that the determining is done " based on the request and NOT on the 
requested content" . 

Since the determination of the additional content is made based upon on the 
request but not the requested content, the determination of the additional content may be 
made in response to receivinq of the request , as defined In independent claim 33, but not 
necessarily waiting for receipt of the requested content. The present invention, with the 
distinguishing features as emphasized above, results in significant differences from the 
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prior art where the additional content Is conventionally determined based on the requested 
content and therefore the determination Is made after the requested content Is available. 
For example, with the present invention, the additional content may be determined 
independently of the requested content, or even when no requested content is available at 
the targeted network server. Furthermore, since the determination can be done In response 
to receiving the request but not receiving the requested content, the additional content can 
be determined earlier and therefore provided to the client system more quickly. 

In an Implementation scenario of the present Invention, the request for content from 
the client system, which Is targeting the network server, is routed to the bridge server. The 
bridge server determines or checks, based on the request , the additional content. After the 
determining, the bridge server returns the request back to the client system for 
resubmission, together with the determined additional content or an identifier of the 
additional content. To avoid re-determining for additional content upon receiving the re- 
submitted request from the client, the original request Is marked up bv the bridge server 
before it Is returned to the client system. Thus, when the bridge server receives the re- 
submitted request from the client system again, the bridge server can recognize from the 
marking previously made bv the bridge server Itself that a determination for additional 
content has already been done to the request, and therefore the bridge server does not do 
the determining of the additional content again, but simply removes the marking and 
fonwards the request to the targeted network server. This distinguishing feature as 
underlined above that the request is marked bv the bridge server is clearly defined In 
independent claims 24 and 29. 
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II. Rejection of independent claim 24 under 35 USC §1 03(a) 

Claim 24 is rejected as being obvious over Haserodt (US Patent No. 6,031 ,836) in 
view of Rondeau (US Patent 5,850. 433) under 25 USC §1 03(a). The applicants 
respectfully traverse this rejection. In particular, the applicants do not agree with the 
assertion of the Examiner that Haserodt teaches to mark up the request bv the bridge 
server and to return the marked up request back to the client for a re-submission. 

Haserodt discloses a method for a client to select server-based telephony features. 
In particular, a web page 1 15 carrying a blank feature form is downloaded from the server 
104 to the client 101 . Then a user of the client 103 uses a browser 113 to mark up the 
blank feature form (i.e., to select the desired telephony features) and uploads the marked 
up page 115 back to the sen/er 104. Upon receiving of the form marked up b v the client 
103 . the server 104 Interprets the selected features and parameters, and then 
communicates with telephony feature server 105 or sends redirection instructions to the 
client 103. It can be found nowhere in Haserodt a teaching or implication that the feature 
form is marked up bv the server 104 . In fact, it is unlikely in Haserodt for the server 1 04 to 
do so since it is the user/client who shall select the desired telephony features by marking 
up the blank form downloaded from the server 1 04. 

Furthermore, in Haserodt, the server 104 does not return the m arked up form/page 
115 back to the client , but only sends redirection instructions to the client and/or 
communicates with the telephony feature server 105. No teaching or implication can be 
found in Haserodt that the redirection instructions include the marked up form/page. In fact, 
there is no need or meaning for sen/er 104 to return the marked up form/page back to the 
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client, since the purpose of marking up by the client is to show the server 104 what 
telephony features are desired by the client. 

To the contrary. It is clearly, unambiguously and repeatedly described in detail 
throughout Haserodt that the feature form/page 115 (reads as "request" in claim 24) is 
marked up bv a user of the client 103 but NOT bv the server 104 (read as "the bridge 
server" in claim 24). For example, it is described in Haserodt that "the user then uses 
browser 1 1 3 to mark up the feature form ... at step 208. When the user is finished, browser 
113 uploads the marked up page 1 15 back to server 104, at step 210... (col. 3, line 67-col. 
4, line 4)", "server 104 receives the marked up page 115, at step 212, ... to interpret the 
marked up page 115, i.e., to determine from the feature form which features the user 
selected, ...at step 214 (col. 4, lines 6 -12)", "upon receipt of the marked up page 115, 
server 104 responds to the user's selection ... (col. 4, lines 45-46, col. 5, lines 1-2, lines 
35-36, lines 52-53, etc.)". This is also clearly shown in Figure 2 of Haserodt patent. A blank 
feature form page is downloaded from the server 1 04 at step 204 (at the middle column) to 
the client (browser 1 13, at the left column), and then the step of marking up the feature 
form is done bvthe browser 113 at step 208, then uploaded at step 210 to the server 104. 
The server 1 04 receives marked up feature form page at 21 2. So, the form provided by the 
server 104 to the client/browser 113 is a blank form, which will be marked up bv the 
browser 113 . and then uploaded to the server 104 again. Server 1 04 does NOT mark the 
form/ page, but receives a marked up form which is marked up by the client/browser. 

Applicants can not locate in Haserodt the statement in the Office Action, cited by 
the Examiner, that "the server 104 generates a marked up request. . ." (italic in the original 
Office Action, on page 4, lines 13-14), which appears to be an important ground for the 
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Examiner to reach his conclusions. A more specific citation from the Examiner would be 

highly appreciated by the applicants. 

The applicants have also reviewed Rondeau (US Patent 5,850, 433) and can not 
find a teaching or implication the features of marking up the request bvthe bridge server 
and returning the marked up request back to the client for a re-submission, as defined in 
independent claim 24, either. 

Therefore, claim 24, with the distinguishing features that the request is marked 
UP bv the bridge server and that the marked up reguest is returned bv the bridge server 
to the client for a re-submission, is not taught either by Haserodt, Rondeau or their 
combination under 35USC §103(a), and is thus patentable. 

III. Rejection of independent claim 29 under 35USC S102(e) 

Claim 29 is rejected as being anticipated by Haserodt (US Patent No. 6,031,836) 
under 35 USC §1 02(e). The applicants have amended claim 29 to more clearly define the 
invention, and believe the amended claim 29 is not anticipated by Haserodt for similar 
reasons as those given for claim 24. 

III. Rejection of dependent claims 25 and 30 under 35USC §103(a) 

Claims 25 and 30 are dependent on independent claims 24 and 29 respectively, and 
are rejected under 35 USC §1 03(a) as obvious over Haserodt in view of Rondeau. 
Applicants respectfully traverse the rejection because, at least for the same reasons that 
the applicants have explained in detail with regard to independent claims 24 and 29, claims 
25 and 30 are also patentable as each having included all the limitations of one of 
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IV. Reiection of independent claims 1. 19 and 33 under 35 USC g103(a) 

Independent claims 1, 19 and 33 are rejected under 35 USC §1 03(a) as being 
obvious over Herz (US Patent No. 5,754,938) in view of Van Hoff (US Patent No. 
5,822,539). The applicants respectfully traverse the rejections. In particular, the applicants 
do not agree with the assertion of the Examiner that Herz or Van Hoff or their combination 
discloses that the determination of additional content is made in the bridge server based on 
the request and not on the recuested content (defined in claims 1 and 19), and/oris made 
in response to the receiving of the request (defined in claim 33). To the contrary, in both 
Herz and Van Hoff, the determination of additional content is made based on the 
requested content (not the request ), and is made after the requested content is available , 
as explained in detail below. 

Herz et al (US Patent No. 5,754,938) discloses a technology typically used for 
effectively searching for desirable objects from information servers by matching object 
profiles of the target objects with the search profiles (target profile interest summary) 
provided by the client. In Herz, a proxy server S2 is provided to stand in communication 
between the client C3 and the information server S4, generally for a privacy protection 
purpose. Basically, the client C3 sends a request to proxy server S2 for information (target 
object) from the information server C4. Upon verification on the client C3, the proxy server 
S2 forwards the request to the information server S4. In col. 39, line 64 to col. 40, line 36, 
Herz also teaches to provide advertisement to the client either from the proxy server S2 
(read as "the bridge server") or from the information server S4 (read as "the targeted 
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network server"). 

However, Herz does not teach that the determination of the advertisement is based 
on the request or is made in response to receivina of the request . To the contrary, in Herz, 
the advertisement is determined based on the tarqet obiect X (requested content) and is 
made after the target obiect X is received . As described in Herz, "if the user has just 
retrieved a tarcet obiect X. then (a) either proxy server S2 . . . determines a weighted set of 
advertisements that are "associated with" tarqet obiect X . ... (col. 40, lines 1-5)", and "in 
the variation where proxy server S2 determines the set of advertisements associated with 
tarqet obiect X . then this set typically consists of all advertisements . . . whose target profiles 
are within a threshold similaritv distance of the target profile of tarqet obiect X (col. 40, lines 
1 0-1 6)". Therefore, the advertisement is detemriined or weighted based on the target obiect 
X (reguested content) and the determination is made after the target obiect X is available . 
Since the advertisement is determined based on the target object X but not the request 
itself, it can NOT be determined upon receiving of the request, and the proxy server has to 
wait until target object X is provided from the information server S4. This is the case in 
Herz where the actions 1 - 9 are listed in seguence (col. 38, line 53-54). 

Van Hoff discloses a technique in which annotation is provided and merged by an 
annotation proxy server to a document requested by a client computer and received from a 
web server. However, Van Hoff does not teach to determine the annotation based on the 
request and NOT on the requested document , or that the annotation is determined jn 
response to receivinq of the request . In contrast, throughout Van Hoff, the annotation is 
determined based on the requested document (read as "requested content"), and in 
particular, on a character pattern found in the document (col. 5, lines 41-45). "In simplest 
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terms, the annotation proxy server parses the requested document and compares the 
characters, words, phrases, and the like with match patterns 195 In the selected annotation 
directory (col.7,lines 1-5)". In fact, this comes from the very nature of annotation since an 
annotation to a document has to be determined based on the document but NOT on the 
request . In this regard, the applicants would like to emphasize that the requested 
information as noted by the Examiner in the Office Action, page 3 is NOT the request . 
Since by its nature the annotation has to be detemnined based on the requested document, 
it is simply impossible for Van Hoff to teach that the annotation be determined in response 
to receiving of the request . In fact, in Van Hoff, the request for document is even not 
necessarily to be received at the proxy server in some circumstance (col. 4, lines 32-35). 

Therefore, the applicants believe independent claims 1, 19 and 33, with the 
distinguishing features absent in both Herz or Van Hoff that the additional content is 
determined based on the request and not on the requested content , and that the 
additional content is determined in response to receiving of the request , are not obvious in 
view of Herz or Van or their combination under 35USC §1 03(a) and are thus patentable. 

V. Rejection on dependent claims 2-4. 1 1 . 17-18. 21 and 34-35 

Dependent claims 2-4, 1 1 , 17-18, 21 , 34 and 35 are rejected under 35 USC §1 03(a) 
as being obvious over Herz in view of Van Hoff. Applicants respectfully traverse the 
rejection because, at least for the same reasons that the applicants have explained in 
detail in regard to independent claims 1, 19 and 33, these dependent claims are also 
patentable as each having included all the limitations of one of three independent claims. 
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In particular, claims 13 and 23 further include a distinguishing feature of "marking 
the received request by the bridge server, and returning by the bridge server to the client 
system, the marked version of the received requested for re-submission by the client 
system" (or similar language), which can not be found in any of the cited patents, for the 
same reasons as explained in detail regarding to independent claim 24. Claim 15 
comprises a feature that the marked version of the request is "appended with additional 
characters identifying the bridge server as the marking bridge server", which can not be 
found in any of the cited patents. Claim 35 is amended to include a feature that the 
additional content is determined based on an identifier which is included in the recuestand 
identifies the targeted network server , which can not be found in any of the cited patents. 
Therefore, dependent claims 13, 15, 23 and 35 are further strengthened in patentability 
because of these distinguishing features. 

VI. Newlv added dependent claims 39-43 

The applicants believe, at least for the same reasons explained above regarding 
their respective base independent claims, these newly added dependent claims are also 
patentable. 

In particular, claims 39, 41 and 42 further define that the additional content is 
"determined by the identifier included in the request" which identifies the targeted network 
server, or "a URL of the network server", which are not disclosed in any of the cited 
patents. Thus, claims 39, 41 and 42 are further strengthened in patentability for these 
distinguishing features. 
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VII. Conclusion 

Applicants believe the application is now in condition for allowance. The Examiner 
is respectfully requested to telephone the undersigned in order to attempt to resolve any 
further issues preventing the case from being passed to allowance. 

The Examiner is authorized to deduct any fees believed due from our Deposit 
Account No. 11-0223. 

Respectfully submitted, 

KAPLAN & GILMAN, L.L.P. 
900 Route 9 North 
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MARKED UP VERSION 

OF Amended CLAIMS 1. 2. 9. 13. 19. 23. 24. 29. 30. 35. 37. 38 



1 . (Now Six Times Amended) In a bridge server, a method comprising: 

receiving by said bridge server from a client system a request for 
content targeting a network server [and not targeting said bridge server], and 

determining by said bridge sen/er, based on said received request 
and not on the requested content , additional content other than the requested content to 
be provided to the client system by the network server; and 

providing by said bridge server said determined additional content 
or an identifier of said additional content to said client system. 

2. (Now Twice Amended) The method of claim 1 wherein said [providing 
comprises providing by said bridge server,] additional content comprises additional 
information regarding said network server to said client system. 

9. (Now Twice Amended) The method of claim 1 , wherein the method further 
comprises automatically establishing and facilitating a voice call to a PSTN handset [by the 
network server] in response to a user of the client system selecting the additional content. 

1 3. (Now Twice Amended) The method of claim 1 , further comprising marking the 
received reouest bv the bridge server, and returning by the bridge server to the client 
system, [a] the marked version of the received requested for re-submission by the client 
system. 

1 9. (Now Five Times Amended) A bridge server comprising: 

control logic operative to receive a request for content from a client system 
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targeting a network server, and to check, based on said received request and not on the 
requested content , whether additional content Is to be provided to the client system, in 
addition to the requested content to be provided to the client system by the network server; 
and 

content-adding logic, coupled to the control logic, operative to provide the 
additional content or an identifier of said additional content to the client system if the 
additional content is to be provided. 

23. (Now Twice Amended) The bridge server of claim 19, wherein the control 
logic is further operative to mark up the request, return the marked up request to the client 
system for re-submission, and upon [re-receive] re-receiving of the marked up request, 
remove the marking, then fon^/ard the request to the targeted network server. 

24. (Now Thrice Amended) In a bridge server, a method comprising: 
receiving by the bridge server a request for content from a client system 

targeting a network server; and 

marking up by the bridge server the received request and returning the 
marked up request to the client system for re-submission [the marking up being performed 
in a manner that specified the additional content to be provided]. 

29. (Now Four Times Amended) A client system comprising: 

means for transmitting a request that targets a network server; [and] 

means for [re-transmitting the request in a marked up form, upon] 
receiving return of the request, from a bridge server, in [said marked up] a form marked up 
by said bridge serve r; and 

means for re-transmitting the request in said marked up form . 
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30. (Now Thrice Amended) The client system of claim 29, further comprising: 
means for transmitting another request for additional content, upon 
receipt of an identifier of the additional content from [a] said bridge server provided in 
response to the first transmission of the request. 

35. (Previously Added and Now Once Amended) The method of claim [34, further 
comprising a step of providing said requested content to said client system] 33. wherein 
said determining is based on an identifier which is included in said request and identifies 



the targeted network server . 

37. (Previously Added and Now Once Amended) The method of claim 36 
wherein said [additional content comprises an] option for making a telephone call is an 
option allowing a user of the client system to make the telephone call without requiring 
provision of a telephone number by a user. 

38. (Previously Added and Now Once Amended) The method of claim 36 
wherein said [additional content comprises an] option for making a telephone call is an 
option allowing a user of the client system to make the telephone call without 
termination of a current client system to network communication session. 
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